RFC 6648
RFC 6648 또는 BCP 178은 텍스트 기반 애플리케이션 프로토콜에 표준에 없는 파라메터를 추가할 때(예: 비표준 HTTP 헤더 추가) 파라메터 이름에 “X-” 프리픽스 혹은 그 유사한 방식의 작명을 쓰지 말라는 가이드라인(BCP)이다.
datatracker.ietf.org/doc/html/rfc6648
RFC 6648 및 관련 문서를 읽고 주요 내용을 요약해보았다.
역사
“X”를 붙이는 작명 관습은 RFC 691에서 처음 제안되었는데, 원래는 “X” 뒤에 바로 다른 단어를 붙이는 식이었다(1975년).
현재의 “X-” 작명에 직접적으로 영향을 준 표준은 RFC 822 - Standard for the format of ARPA Internet text messages이다(1982년).
RFC 822는 확장 필드(extension-fields)와 사용자 정의 필드(user-defined fields)를 구분하는데, 확장 필드는 아직 표준화되지 않았지만 추후에 추가될 필드들을 말하고, 사용자 정의 필드는 표준화 여부와 무관하게 정의해서 쓸 수 있는 필드를 말하는데, 해당 문서에서는 확장 필드 이름에는 절대 “X-”을 쓰지 말고 사용자 정의 필드는 반드시 “X-”을 써야 한다고 명시한다. 이는 사용자 정의 필드를 위한 안전한 이름 공간을 만들기 위한 제안이었다.
다만, RFC 822는 2001년에 RFC 2822 - Internet message format에 의해 갱신되는데 이때부터는 더이상 확장 필드와 사용자 정의 필드를 구분하지 않고 있고, 따라서 “X-” 작명에 대해서도 더이상 언급하지 않고 있다. RFC 6648에 의하면 RFC 2822로 인해 이메일 헤더에서 “X-”의 사용은 실질적으로 더이상 권장되지 않게 되었다(“effectively deprecated”).
그럼에도 불구하고 “X-” 프리픽스는 RFC 822 이후로 MIME 타입, HTTP 헤더, LDAP 필드명 등 다양한 RFC로 널리 확장된다.
문제점
“X-” 프리픽스의 문제 중 하나는 “X-” 이름을 달고 쓰이기 시작한 비표준 헤더들이 여러 구현에 의해 널리 채택되면서 결국은 표준 이름 공간을 침범해 들어오곤 한다는 점이다. “X-blah”가 표준화되면 결국 “blah”라는 표준 이름으로 바꾸는 마이그레이션이 필요한데 이는 상호운용성 문제를 야기할 수 있다. 왜냐하면 옛날 구현체들은 표준 이름 “blah”가 아닌 옛날 이름 “X-blah”만 지원하기 때문이다. 이 문제를 해소하려면 새로운 구현체들이 “blah”와 “X-blah”를 모두 지원해야 하는데, 그건 곧 “X-blah”가 사실상의 표준(de facto standard)가 된다는 뜻이며, 이는 애초의 목적(비표준 확장을 위한 안전한 이름 공간을 확보하기 위해 표준 이름에는 “X-”을 쓰지 않겠다는 약속)에 반하는 결과로 귀결된다.
일례로 RFC 2068 - HTTP/1.1 중 “3.5. Content Codings”에는 이런 문구가 나온다.
기존 HTTP 구현과의 호환성을 유지하기 위해 애플리케이션은 “x-gzip”과 “x-compress”를 각각 “gzip”, “compress”와 동일하게 취급해야 한다.
“X-”의 또다른 문제는 비표준이었던 “X-blah”를 “blah”로 표준화하면서 원래의 비표준 구현과 미묘하게 달라질 수 있다는 점이다(예: 비표준 구현의 표준화를 검토하는 과정에서 보안 문제를 개선. 사례: RFC 5727). 이런 경우 “X-blah”와 “blah”는 실질적으로 다름에도 불구하고 이 둘을 동일하게 취급함으로써 상호운용성 문제 또는 보안 문제가 발생할 여지가 생긴다.
제안
RFC 6648는 애플리케이션을 구현할 때, 새 파라메터를 추가할 때, 새 프로토콜을 설계할 때 각각 따라야 할 지침을 담고 있는데, 이 중 애플리케이션 구현 및 새 파라메터 추가와 관련한 지침은 아래와 같다.
- 애플리케이션 구현 시 파라메터 이름에 “X-”가 있는지 없는지를 기준으로 해당 파라메터의 지위(status; 표준인지 비표준인지)에 대해 어떠한 가정도 하지 말 것.
- 새 파라메터를 추가할 때 해당 파라메터가 표준화되거나 널리 수용될 가능성을 언제나 염두에 둘 것. (단 Appendix B.에 따르면, 새로 추가하려는 파라메터가 표준화되거나 널리 수용될 가능성이 극히 적다면, 회사 이름이나 도메인 이름 등을 붙여서 이름 공간을 구분할 수 있다. 예:
vnd.somecompany.someproduct) - 새 파라메터를 추가할 때 이름 충돌이 없을 가능성이 충분히 높으면서도 의미있는 이름을 지어줄 것.
- 새 파라메터를 추가할 때 “X-” 등 비표준임을 알리기 위한 전치사 같은 걸 붙이지 말 것.
CSS vendor prefix 사례
RFC 6648에 의하면 벤더 프리픽스는 표준화 가능성이 거의 희박한 경우에만 사용하라고 권하고 있다. 하지만 CSS의 경우 표준화 가능성이 상당히 높은 확장 기능을 추가할 때 -webkit-transform, -moz-transform 마냥 벤더 프리픽스를 사용해왔다. (참고로 RFC는 IETF 표준이고, CSS는 W3C 표준이다.)
이 방식은 당연히 위에서 설명한 여러 문제를 두루 겪었다(지금도 겪고 있다). 일부 벤더 프리픽스가 표준처럼 쓰이는 문제(예: -webkit-을 다른 브라우저에서도 구현), 호환성을 유지하기 위해 프리픽스를 계속 붙여야 하는 문제 등.
CSS를 작성하는 입장에서는 autoprefixer 같은 툴을 쓰면 “Can I Use” 데이터베이스를 활용하여 자동으로 벤더 프리픽스 관리할 수 있긴 하지만, 이런 류의 빌드 툴이 많이 필요하다는 건 보통 플랫폼에 뭔가 문제가 있다는 뜻이다.
벤더 프리픽스를 써야만 하는 CSS 속성은 약 2011년 즈음까지 꾸준히 증가해왔는데 2012년부터 서서히 감소한다.1 2013년에 모질라가 position: sticky를 피처 플래그(feature flags) 형태로 지원하기 시작했고,2 2016년에 웹킷이 더이상 새 속성을 벤더 프리픽스 형태로 추가하지 않겠다고 선언하면서3 벤더 프리픽스의 필요성이 서서히 줄고 있다.